Network Supervisor's Toolkit/Network Supervisor's Toolkit.iso/tools/nwtp06/appn9008.txt

Text File | 1996-07-10 | 15KB | 289 lines

(Note: AppNote August 1990)

A Comparison of NetWare IPX, SPX and NetBIOS

 Bill Bodine
 Consultant
 Systems Engineering Division

Abstract:

One of the first questions always asked during comparisons of NetWare
IPX, SPX and NetBIOS is which of these protocols will transfer data
the fastest, and how much slower the others are. This AppNote details
the results of four benchmarks written to illustrate the relative
speed of each of these communication interfaces. Performance, maximum
packet length, naming capabilities and memory usage are each singled
out as additional factors in the decision to implement systems using
these protocols. Clarification and explanation of SHELL.CFG parameters
are also included.

Novell, Inc. makes no representations or warranties with respect to
the contents or use of these Application Notes, or any of the third-party
products discussed in the AppNotes. Novell reserves the right to revise
these Application Notes and to make changes in their contents at any
time, without obligation to notify any person or entity of such revisions
or changes. These AppNotes do not constitute an endorsement of the
third-party product or products that were tested. The configuration
or configurations tested or described may or may not be the only available
solution. Any test is not a determination of product quality or
correctness, nor does it ensure compliance with any federal, state or local
requirements. Novell does not warranty products except as stated in
applicable Novell product warranties or license agreements.

Copyright { 1990 by Novell, Inc., Provo, Utah. All rights reserved.

As a means of promoting NetWare Application Notes, Novell grants you
without charge the right to reproduce, distribute and use copies of
the AppNotes provided you do not receive any payment, commercial benefit
or other consideration for the reproduction or distribution, or change
any copyright notices appearing on or in the document.

Introduction

When Novell began operations in 1982, several proprietary protocols
for transferring data between workstations were used. As time went
on, the decision was made to base Novell's network communications
on a fast and efficient networking standard. Xerox's XNS protocol
was determined to be one of the best available at the time so Novell's
Internetwork Packet Exchange (IPX) protocol was developed to conform
to the XNS standard. NetWare IPX is functionally equivalent to Xerox's
Internet Datagram Protocol (IDP).

This AppNote discusses the three primary peer-to-peer protocols
that are supported in the NetWare LAN environment-NetWare IPX, SPX
and NetBIOS. Additional protocols supported include the Transport
Layer Interface (TLI), Named Pipes, LU6.2 and others, but are not
covered in this AppNote.

NetWare IPX

NetWare IPX is a true datagram protocol. It makes a best-effort
attempt to send packets by using a 12-byte addressing scheme.
The 12-byte address is split into three addresses: the network
address, which is used to address individual workgroups; the node
address, which addresses network nodes within the workgroups; and
the socket address, which can be used to multiplex between functions
within a network node. When sending an NetWare IPX packet from one
node to another, the sending node must know the receiving node's 12-byte
address.

SPX

The Sequenced Packet Exchange protocol (SPX) is a connection-oriented
communications protocol that is built upon NetWare IPX. When a call
is made to SPX to send a packet by an application program, SPX will
do some housekeeping-type work on the packet, but will call NetWare
IPX to actually send the packet. SPX guarantees packet delivery, whereas
NetWare IPX only gives a best effort to deliver packets. This added
feature of SPX has obvious advantages, but as we shall see later in
the paper, it also adds overhead to the data transfer cycle and is
slower.

NetBIOS

The Network Basic Input/Output System (NetBIOS) functions in either
a connectionless mode or a connection-oriented mode. An application
written to the NetBIOS interface can be designed to use either of
these modes. For instance, if an application functions in a request/reply
mode with a transfer size of only one packet, then the connectionless
mode should be used to take advantage of connectionless response times.
On the other hand, if most of the transfers are one-sided or consist
of large numbers of packets, the transfers should use the connection-
oriented mode in order to ensure packet delivery and integrity of data.
Novell's NetBIOS emulator is built upon NetWare IPX in the same way
that SPX is.

The NetBIOS emulator is called an emulator because it is implemented
entirely in software, whereas the original NetBIOS introduced by IBM
and Sytek was located in firmware.

Because NetBIOS was introduced by IBM, it was almost instantly accepted
as an industry standard. Most networking vendors have implemented
the specification given by IBM that allows almost any application
written to the NetBIOS interface to operate in any environment.

A common problem with the NetBIOS specification, however, is that
it only deals with the upper layer functions of the interface. It
does not specify what communications protocol should be used underneath
it. As a result, almost every networking vendor has written NetBIOS
on top of their own proprietary communications protocol, which cannot
communicate with other vendors' protocols.

A nice feature that NetBIOS has to offer the networking industry is
its allowance of easy address resolution among locally-connected
workstations. All nodes on a network that use NetBIOS register a unique
name. When a node desires to communicate with another node, all it
needs to know is the node's unique NetBIOS name and NetBIOS will ensure
that the packet arrives at the proper location.

Performance Results

One of the first questions regarding the comparison of NetWare IPX,
SPX and NetBIOS is which of these protocols will transfer data the
fastest, and how much slower the others are. As part of this AppNote,
four benchmarks have been written to illustrate the relative speed
of each of these communications interfaces. The scope of the benchmark
is relatively simple-to send 2,000 255-byte packets and to record
the time that it takes for the transfer to complete. All the programs
were written by the same person and were intentionally kept as simple
as possible to make each benchmark represent the speed of the interface
and not efficiencies or lack thereof in the benchmark tests.

Each of the benchmarks encompassed two programs. One program
was used to send packets and the other was used to receive. The sending
side sent a packet and then incremented a counter. Before the packet
was sent, a call was made by the sender to the system clock. Once
the 2,000th packet had been sent successfully, another call was made
to the system clock. The first value was subtracted from the second
and the result represented the time in clock ticks that it took to
send 2,000 packets on the given communication interface. The receiving
side did nothing but receive packets and count the number that arrived.
No other processing took place within the code.

The following results were achieved on standard 8MHz 80286-based
machines on a 4MB Token-Ring network. While the test does not
represent any real-world scenario, it does indicate the relative
speed of each interface tested.

     NetWare IPX              366.0 packets per second

     SPX                      140.3 packets per second

     Novell NetBIOS datagram  224.8 packets per second

     Novell NetBIOS session   135.9 packets per second

NetWare IPX is the fastest protocol available from Novell. This is
expected since all others are written in terms of NetWare IPX. SPX
and NetBIOS are slower than NetWare IPX due to the extra overhead
they introduce into the communications process. SPX and the NetBIOS
session level interface run at virtually the same speed. They both
have to maintain the same level of connection overhead for the
guaranteeing of packets and are both written in terms of another
interface.

Other Decision Criteria

There are a few primary differences between writing an application
to NetWare IPX or SPX and writing an application to NetBIOS. Two of
these differences deal with the maximum length of packets that can
be sent and the address resolution.

Maximum Packet Length

With NetWare IPX and SPX the maximum packet size that can be sent
by an application depends on either of two things. If the packet to
be sent must cross a NetWare bridge, the maximum packet size possible
is 576 bytes. The bridge will drop any packets that exceed this size.

On the other hand, if the packet will not be crossing any bridges,
the network interface card (NIC) drivers limit the size. While most
drivers allow packets of 1,024 bytes or larger to be transferred,
NetWare documentation recommends that the maximum size transferred
be 576 bytes. This is in case the packet crosses a bridge or the driver
cannot handle larger packets.

NetBIOS allows an application to send packets up to 64KB in size.
This is possible because the NetBIOS emulator breaks the packet into
smaller packets for the application and sends them out in sizes that
can be handled by NetWare IPX and the NIC drivers. While this feature
is useful, some developers choose to split packets up themselves in
order to optimize the NetWare IPX bandwidth for their application.
This may or may not be a factor in different situations.

Naming Capabilities

The second primary difference is the naming capability supplied with
NetBIOS. NetBIOS makes it convenient for an application to determine
the addresses of other nodes on the network. Each workstation identifies
itself with a particular name. Once any other workstation on the LAN
knows that name, data can be sent between the two workstations.

Novell recognized the need for this easy address resolution when it
developed NetWare IPX, so the Service Advertising Protocol (SAP) was
developed. With SAP, a node advertises, or broadcasts to the entire
network its name and address. This name and address are stored internally
on all NetWare network file servers. When any other node wants to
find an address, it queries a NetWare file server and the necessary
information is returned. There are also other ways of finding an address
without accessing the NetWare file server, but they are not as common.

Both of these methods have advantages and disadvantages. While it
is probably easier for an application with the naming capability of
NetBIOS to be developed, using the SAP provided by NetWare does not
require much more work. The advantage gained by using the SAP is that
once the address is resolved, the underlying protocol is very fast.
The SAP is designed for a client-server environment, which means
that a client always initiates a dialogue with the server. The client
can always find the server's address through the SAP. Since all packets
on the network contain the 12-byte address of the node they were
sent from, the server will know which address to send responses to.

Memory Usage

When an application runs on a network workstation, particularly in
the DOS environment, the amount of memory that is free for the application
to use is often a primary concern. In NetWare the first software to
load on the network is a terminate-and-stay-resident (TSR)
program called IPX.COM. This program contains all the interfaces needed
to run NetWare IPX programs and SPX, and uses about 14KB of workstation
memory. This is the only piece of NetWare software that needs to be
run in the workstation if no communications are needed with any file
servers. If a file server is needed, the TSR NET3.COM is loaded after
IPX.COM. This program contains all the functions needed by the workstation
to communicate with any NetWare file server on the LAN. It uses about
38KB of workstation memory. NetBIOS is an optional TSR like NET3.
IPX.COM must be loaded first. When NetBIOS is loaded it takes up about
30KB of workstation memory. Just as NET3 is only used when communications
are sent to a NetWare file server, NetBIOS is only run if an application
needs to use the NetBIOS services. Native NetWare does not use NetBIOS
for any of its communications services.

Appendix A lists parameters that have been modified in the recent
versions of NetBIOS. Because of the differences among versions, they
will be discussed as they relate to the specific versions.

The values listed in Appendix A are approximates. It is not possible
to state exactly how much memory any of the three protocols will use
up because they all contain custom parameters that change their sizes
and configurations. The parameters that alter these configurations
are located in a file named SHELL.CFG. As IPX.COM or NetBIOS.EXE is
loaded, it looks for this file in the local directory or a search
directory. Once it locates SHELL.CFG it searches within the file to
determine if any of its default parameters have been altered. These
parameters can be configured from within the SHELL.CFG file. Appendix
B of the NetWare Supervisor Reference manual also explains
the parameters.

Conclusion

While the primary advantage of writing to NetWare IPX is speed, the
main advantage of writing to NetBIOS is that the application will
work on other environments in addition to NetWare. This should obviously
be considered for applications that are marketed on a variety of platforms.

Even though different vendors' NetBIOSs can rarely communicate with
each other, most applications do port well over these vendors'
implementations.

There are a variety of reasons applications are developed to
one protocol or another. One reason a protocol is chosen is because
it is perceived as the defacto standard. For many developers, NetBIOS
is seen as a standard. Applications are developed to that platform
for reasons of portability to a variety of environments. On the other
hand, many developers are developing to NetWare IPX because they recognize
NetWare's large market share and want to reach the greatest market
possible with the most efficient protocol available.

Sometimes, one protocol may be perceived as easier to develop to than
another. Of course whether one is actually easier than another depends
entirely on the resources that are available, such as the Novell C
Interface libraries for NetWare IPX and SPX, the experience of the
development team or even available documentation and training.

Appendix A: SHELL.CFG Parameters

******* Note: The appendix (mostly outdated info) has been removed ********